home *** CD-ROM | disk | FTP | other *** search
- Date: Tue, 19 Jul 1994 02:20:39 -0400 (EDT)
- From: Timothy Miller <millert@undergrad.csee.usf.edu>
- Subject: Amodal Dialogs, etc.
- To: gem-list@world.std.com
- In-Reply-To: <Pine.3.89.9407182352.A5860-0100000@mhc.mtholyoke.edu>
- Message-Id: <Pine.3.87.9407190239.A15671-0100000@grad>
- Mime-Version: 1.0
- Precedence: bulk
-
- Well, with all this discussion of amodal dialogs, etc., I have been
- prompted to write my own. At first, it was just to see if I could do it,
- but I added it to a program I'd written and was very pleased with the
- results. There was discussion on Gem-list about how difficult it is to
- handle sliders on some amodal dialog package or other.
-
- So I decided to put code into my handler that would handle sliders with
- the requirements that it should be as easy and transparent to the developer
- as possible and placing as much information as possible in the resource
- file, not the program source code. After a little design work, I came up
- with something I liked, but I figure it's probably not a new way of doing
- it.
-
- In the resource editor, you begin by creating a BOXTEXT object and put
- into it 4 6-digit numbers corresponding to the following:
- 1. lowest value for result
- 2. highest value for result
- 3. current value
- 4. size of slider relative to high/low values and used for distance to
- page "up" or "down".
- Plus a single character specifying:
- 5. '+' sign if slider physical size will be relative to (4) within range.
- Anything else will keep slider size constant at what is set in RSC
- file.
- Assign to this object an extended object type of 1 for vertical or 6 for
- horizontal.
-
- On top of that (and obscuring it), you place a left/up button (extended
- object type 3), a right/down button (type 4), and a slider box/frame (type
- 2). On top of the box, place a slider (type 5). NONE of the objects
- should have any flags set (ie. do not make them touch-exit). All objects
- should have the same proper height or width, depending on orientation,
- and they should all have a border size of -1. Only the parent BOXTEXT
- object need be given a name, unless the slider, for example, is a BOXTEXT
- that displays a value.
-
- For the program source code, there is little to worry about. If the
- slider position and size in the resource file do not correspond to the
- numbers you placed in the parent BOXTEXT, then you can kick them into
- place by calling a routine immediately after you initialize the dialog.
-
- Whenever a slider event occurs, it is of no concern to the programmer what
- button was pressed or whatever, so my routines return the object number of
- the parent like any other button press elsewhere on the dialog so that the
- programmer can pick the numbers out of the TEDINFO for that TEXTBOX at his
- leisure. The numbers are automatically maintained by my code, so you
- need only retrieve the position, and can, if desired, leave the other
- numbers as they were entered in the resource editor.
-
-
- In addition to this, I decided that I wanted to keep the title of the
- window stored in the resource file also. When the dialog is initialized,
- the object number of any object with a TEDINFO is passed to the service
- routine and the title is retreived from there.
-
-
- Tell me what you think. Is this too complicated? If so, what better way
- do you suggest? I intend to release my source code for use by Atari
- developers, although I have not determined how I will handle
- compensation. (I could charge developers who use it a small one-time fee.)
-
-
-